Construction of Engineering Ontologies for Knowledge Sharing and Reuse

Ontologies A second way for modularization is to make ontologies that define abstract concepts. These abstract abstract concepts can be used to define more specific concepts in different domains. An example of abstract concepts are taxonomies. A taxonomy is a structured overview of classes, subclasses and instances. Taxonomies can not only be found in biology, but also in engineering domains. Chapter 4, for instance, describes a library of reusable simulation models in which the component models can be accessed using a component taxonomy. Other examples of abstract ontologies are mereology (part-of relationships), topology (connected-to relationship), and systems theory which are discussed in Chapter 3. Ontologies of graph-theory and of state-space are briefly described in Chapter 5. Method Ontologies The third type of ontologies are method ontologies. Method ontologies define the way domain knowledge can be used to perform certain tasks. For the forage on2.4. THE PROBLEM: USEFUL ONTOLOGIES WILL BE BIG 19 tology we have already seen that there are various ways in which domain knowledge (facts) can be used to classify an animal species. In one application, information in a database was searched for. In another application, facts (the type of food a species eats) were acquired from the user and reasoned with to infer the kind of species. Both for searching and for logical reasoning general problem solving methods exist. For searching, there are for example sequential and binary search methods. Examples In the field of logical reasoning are inductive and abductive reasoning. These methods are general in the sense that they are independent of the domain that is reasoned about. A method ontology includes the definition of a terminology for expressing the competence and the knowledge requirements of a method (Fensel, Schönegge, Groenboom, and Wielinga 1996). For search methods this terminology could include the concept of records, which are group of related domain facts, keys on which all facts in a record uniquely depend and queries that define the records we are interested in. The two search methods that have a different competence. Sequential search generally takes more time than binary search, but the latter has an additional knowledge requirement. For binary search there must be an ordering relation defined for the keys, and the records must be sorted accordingly. The way method ontologies can be linked to domain ontologies is explained in (Gennari, Tu, Rothenfluh, and Musen 1994) and in Chapter 5 of this thesis. Application Ontologies Ontologies that are used for the design of an application are called application ontologies. Generally, they consist of a domain ontology and methods from a method ontology. The methods specify the way the functionality of the application is achieved. Therefore, application ontologies are less suited for reuse for other applications. The degree to which knowledge can be formalized in reusable ontologies is strongly affected by the interaction problem, presented by Bylander and Chandrasekaran (1988): Representing knowledge for the purpose of solving some problem is strongly affected by the nature of the problem and the inference strategy to be applied to the problem (Bylander and Chandrasekaran 1988). Interpreting this problem in a pessimistic way, one could say that it is hardly possible to write a domain ontology that can be reused across many applications because each application will have different tasks and use different methods to accomplish the tasks. We argue however, that although it is not feasible nor desirable to write one domain ontology that is appropriate for all tasks in a domain, it is possible to write a domain ontology that can be shared across large groups of applications. Again, the key factor is modularity. Domain knowledge that is shared by all applications should be specified in a separate core ontology. Task dependent extensions to, or axioms restricting this core knowledge can then be specified in additional ontologies. This provides us another principle for modularization: separate knowledge that is specific for a small group of tasks from knowledge that is less task specific. 20 CHAPTER 2. WHAT IS A USEFUL ONTOLOGY? 2.4.2 Conquer: Ontology Construction Modularizing domain knowledge in manageable ontologies is one part of the solution, but in order to assemble them into large and complex domain ontologies, a mechanism to combine ontologies is required. We call this assembling of small ontologies ontology construction. In the Ontolingua system version 4.0, ontology construction is supported by ontology inclusion. Inclusion of an ontology in another means that definitions of the first theory are added to the second. The current version of Ontolingua offers additional facilities to resolve naming conflicts when an ontology that defines a term includes an ontology that defines a conceptually different term with the same name. Furthermore, there is a mechanism to handle polymorfism. This allows existing operators to be extended to work on new classes (for instance the + operator means addition for numbers and concatenation for strings). What we think is a disadvantage of the present inclusion mechanism, is that it is a pure syntactical operation. If large ontologies are constructed by combining smaller ontologies, the inclusion operator should make explicit the relationship between the combined knowledge: are different viewpoints combined, are abstract concepts used to define more specific ones or is the knowledge merely extended? This kind of informative mechanisms would help to understand large ontologies. This is important, because in order to reuse an ontology, the contents of it must be understood by the ontological engineer. 2.4.3 Libraries of Ontologies To deal with large ontologies, large and complex domain ontologies are modularized in smaller, manageable ontologies of different kinds. Many of these ontologies will be reusable for different applications. Domain ontologies can be reused because they define domain knowledge that can be used for a large group of applications and problem solving methods. Domain viewpoints can be candidates for reuse because they define compact and coherent pieces of knowledge in a domain. Because subdomains generally consist of a subset of the views of an entire domain, it is likely they can be shared across many subdomains. Abstract ontologies are especially suited for reuse. Many domain concepts can be defined as specializations of abstract concepts. The domain concepts will then comply to the same properties as the abstract concepts. Method ontologies can be reused because they define generic problem-solving methods that can applied in different domains. To allow that the above mentioned ontologies can be reused by different people they need to be shared. A common way to share knowledge is by using a library. The Ontolingua system supports such a publicly accessible library of ontologies. Ontological engineers can submit 2.5. THE ROLE OF ONTOLOGIES IN INFORMATION SYSTEMS DEVELOPMENT 21 ontologies to this library or use ontologies from the library for ontology construction. To access the ontologies in the library, the library system offers different kinds of information such as an inclusion lattice of the ontologies in the library. Furthermore, automatically generated reports of ontologies can be inspected. These reports give an overview of the terms defined in the ontology as well as the terms included from other ontologies. One aspect in which ontology libraries need to be improved is their support to retrieve an appropriate ontology in the library. Although the library system presents some information about the ontologies, we think this is not enough to support reuse sufficiently. The relationships between the contents of the ontologies have to be presented. Differences between alternative ontologies for a domain or domain view have to be made explicit. For method ontologies, similarities and differences between the problems they solve should be visible. Abstract and method ontologies should give indications in which domains they can be of use. With this information an appropriate ontology can be retrieved without having to study the definitions in every ontology in detail. 2.5 The Role of Ontologies in Information Systems Development The usual way ontologies are used in information systems development is by construction of an application ontology. This application ontology then serves as a specification of the application' s data structures and the inference engine that performs the application' s tasks. In the first part of this section we will describe the design process in which the application ontology is constructed. The second part gives a comparison between ontology-based development and other approaches in (non-AI) computer science. 2.5.1 In Artificial Intelligence Most of the current approaches (for instance PROTÉGÉ-II (Gennari, Tu, Rothenfluh, and Musen 1994)) to construct an application ontology include the following steps: 1. construct the domain ontology 2. determine which problem solving methods perform the application' s tasks 3. relate the knowledge required by the selected methods to domain knowledge 4. add factual knowledge about the domain Some steps can be executed concurrently by different persons, for instance Step 1 and 2. Step 1, 2, and 3 may need to be iterated for the domain ontology to converge to the selected methods. The addition of domain knowledge can sometimes be supported by knowledge 22 CHAPTER 2. WHAT IS A USEFUL ONTOLOGY? acquisition tools based on the domain ontology constructed in Step 1. The result is the application ontology for the information system. In (van Heijst, Schreiber, and Wielinga 1997), Van Heijst discusses the problem of knowledge-based integration of representation formalisms. The off the shelf problem solvers that are used to implement the application often require different knowledge representation formalisms. The solution he proposes is to use the application ontology as a specification of a common knowledge representation. Inferences of problem solvers using other representations are translated to and from this common representation. As we will see in Chapter 5, the same solution has been used for the development of a prototype knowledge based system. There, we used functions that translate data from C data structures to the form required for the problem solving methods. 2.5.2 In Information Systems Development and Object Orientation The role of application ontologies for information systems design does not differ much from more conventional system design principles in software design, such as semantic modelling (entity/relationship diagrams and object models), meta-data, design and analysis patterns and the use of libraries of reusable software modules. We will discuss the main differences between these approaches and the ontological approach and explain the added value of the latter. Reusable Software Modules Libraries of problem-solving methods are very similar to libraries of reusable software modules. Both contain pieces of software that can be used for different tasks in different domains. Method ontologies serve as a specification for the competence and knowledge requirements of the methods in these libraries. Therefore, the application ontology constructed in the ontological approach makes explicit how the domain tasks are related to the generic task performed and which domain knowledge is used. Semantic Modelling An entity/relationship diagram is a conceptual specification of the data in an information system. It defines the concepts that are distinguished, the properties they can have and the relations between entities. Furthermore, a class–subclass hierarchy between entities can be defined which causes inheritance of properties and relations. The Ontolingua frame ontology is a formal definition of this way of specification of knowledge. Therefore, every entity/relationshipdiagram can be captured in an ontology. Ontologies however have the ability to specify domain knowledge in a much richer and structured way. Object models can be viewed upon as entity/relationship diagrams with an extension that attaches methods to objects (inheritance also applies to these methods). In the ontological approach, these methods specified in method ontologies can also be related to domain objects. Application ontologies can therefore be used to express object oriented models (Takagaki and Wand 1991). 2.6. ONTOLOGIES AS INFORMATION SYSTEM SPECIFICATIONS 23 Meta-Data In database systems development, specifications of the properties of objects and relations is called meta-data. Meta-data can be used to check the consistency of the data in the system. Because domain ontologies are developed to capture this meta-knowledge, meta-data can be easily derived from a domain ontology. The ontological approach has the benefit that the principles of ontology construction can be used to define meta-knowledge in a structured way. Object Oriented Design and Analysis Patterns A very interesting development in the field of object oriented analysis and design is the use of patterns (Coad 1992; Gamma, Helm, Johnson, and Vlissides 1995; Partridge 1996; Fowler 1997). Analysis patterns are meta-level descriptions of pieces of object models that frequently occur in object oriented analysis. Design patterns are similar, but have pieces of code attached to it, so they can be used for object oriented design. Analysis patterns are similar to domain ontologies and design patterns to application ontologies. The benefit of using ontologies instead of patterns is that ontology construction offers a way for constructing complex ontologies from smaller ones. Furthermore, using abstract ontologies it is possible to specify knowledge at higher knowledge levels. In pattern terminology this means that patterns of patterns can be specified. The great benefit of design patterns is that the methods defined for them are tuned to the object oriented knowledge representation. Thus, the problem of knowledge representation integration is got around. Application development using design patterns is therefore less time consuming than ontology-based development. On the other hand, ontologies are not restricted to object oriented knowledge and methods. We think that the fields of object orientation and ontological engineering can learn a lot from one another' s achievements. Analysis and design patterns are collected in libraries. Like ontology libraries, these pattern libraries also lack good support for accessing the contents of large libraries. 2.6 Ontologies as Information System Specifications We conclude this chapter by summarizing the most important findings. Ontologies are formal specifications of shared conceptualizations. They can be the instruments for knowledge sharing and reuse. Ontologies can support information systems design because they specify the knowledge an information system must capture to perform its tasks. To be (re)usable, ontologies should not capture facts about instances in the domain, but make explicit tacit and meta-level knowledge. Ontologies are usually specified in representation languages based on predicate logic. Ontologies can be constructed from smaller modules that are ontologies themselves. Different types of these smaller ontologies can be distinguished: domain ontologies, domain viewpoint ontologies, abstract ontologies and method ontologies. Many of these ontologies can be reused across different domains and applications. A good way to support sharing and reuse of ontologies is to include them in a publicly accessible ontology library. 24 CHAPTER 2. WHAT IS A USEFUL ONTOLOGY? By combining a domain ontology and different method ontologies and adding domain facts, an application ontology can be constructed. An application ontology specifies how the application' s functionalitycan be implemented and which domain knowledge is required. As such, application ontologies play a similar role in information systems design as entity-relationship diagrams, object models, and object patterns. The benefit of ontologies is that they are better suited for piecemeal specification of complex structured domain knowledge, that they make explicit the way domain tasks are performed and that they are independent of the application' s implementation language. In the next chapters we will leave the animals in this chapter in peace and start the investigation of the use of ontologies for complex applications in a large, technical domain.